The majority of attacks occur (or at least commence) late at night relative to the position of the server. That is, if you are in Los Angeles and your attacker is in London, the attack will probably occur during the late night-early morning hours Los Angeles time. You might think that crackers would work during the day (relative to the target) because the heavy traffic might obscure their activity. There are several reasons, however, why crackers avoid such times:
With such machines, you can temporarily take over, setting things to your particular tastes. Moreover, you have plenty of time to alter the logs. So be advised: Most of this activity happens at night relative to your geographical location.
TIP: If you have been doing heavy logging and you have only limited time and resources to conduct analysis of those logs, I would concentrate more on the late night connection requests. These portions of your logs will undoubtedly produce interesting and bizarre information.
The most obvious reason for this is cost. For the price of a $39 book on Linux (with the accompanying CD-ROM), a cracker gets everything he could ever need in the way of tools: C, C++, Smalltalk, Perl, TCP/IP, and much more. Moreover, he gets the full source code to his operating system.
This cost issue is not trivial. Even older workstations can be expensive. Your money will buy more computing power if you stay with an IBM compatible. Today, you can get a 100MHz PC with 8MB of RAM for $300. You can put either FreeBSD or Linux on that machine and suddenly, you have a powerful workstation. Conversely, that same $300 might buy you a 25MHz SPARCstation 1 with a disk, monitor, and keyboard kit. Or perhaps an ELC with an external disk and 16MB of RAM. Compounding this is the problem of software. If you get an old Sun, chances are that you will also be receiving SunOS 4.1.x. If so, a C compiler (cc) comes stock. However, if you buy an RS/6000 with AIX 4.1.x, you get a better deal on the machine but you are forced to get a C compiler. This will probably entail getting GCC from the Internet. As you might guess, a C compiler is imperative. Without it, you cannot build the majority of tools distributed from the void. This is a big consideration and one reason that Linux is becoming much more popular.
I should mention that professional crackers (those who get paid for their work) can probably afford any system. You can bet that those forces in American intelligence investigating cyberwar are using some extreme computing power. For these individuals, licensing and cost are not issues.
NOTE: Compatibility is not really an issue. The majority of good tools are written under the UNIX environment and these can be easily ported to the free UNIX platforms. In fact, in many cases, binaries for Linux and FreeBSD already exist (although I readily admit that this is more prevalent for FreeBSD, as early implementations of Linux had a somewhat eclectic source tree that probably more closely resembled AIX than other traditional flavors, like SunOS). This is somewhat of a cult issue as well. Purists generally prefer BSD.
Moreover, NT is becoming more popular because crackers know they must learn this platform. As NT becomes a more popular platform for Internet servers (and it will, with the recent commitments between DEC and Microsoft), crackers will need to know how to crack these machines. Moreover, security professionals will also develop tools to test internal NT security. Thus, you will see a dramatic rise in the use of NT as a cracking platform.
NOTE: Windows 95 tools are also rapidly emerging, which will greatly alter the state of cracking on the Net. Such tools are typically point and click, requiring little skill on the part of the operator. As these tools become more common, you can expect even more security violations on the Net. Nonetheless, I don't think 95 will ever be a major platform for serious crackers.
Today the situation is entirely different. Crackers can crack your network from their home, office, or vehicle. However, there are some constants. For instance, serious crackers do not generally use providers such as America Online, Prodigy, or Microsoft Network. (The obvious exceptions are those crackers who utilize stolen credit-card numbers. In those cases, AOL is an excellent choice.) One reason for this is that these providers will roll over a hacker or cracker to the authorities at the drop of a hat. The suspect may not have even done anything wrong (smaller ISPs may simply cut them loose). Ironically, big providers allow spammers to pummel the Internet with largely unwanted advertising. Go figure. Curiosity is frowned upon, but stone-cold commercialism is A-OK.
Furthermore, these providers do not offer a UNIX shell environment in addition to garden-variety PPP. A shell account can facilitate many actions that are otherwise more difficult to undertake. System tools available that can provide increased functionality include the various shells, Perl, AWK, SED, C, C++, and a handful of system commands (showmount is one; rusers is another).
So the picture of a typical cracker is developing: This is a person who works late at night, who is armed with a UNIX or an NT box and advanced tools, and, with all likelihood, is using a local provider.
This profile, however, is not set in stone. Many crackers prefer to run with the bleeding-edge target, seeing whether they can exploit a newly discovered hole before the sysad plugs it. In this instance, the cracker is probably cracking for sport.
NOTE: Seizing such a network is generally easier, as it is maintaining a box there. Crackers refer to this as owning a box, as in "I just cracked this network and I now own a box there." This owning refers to a condition where the cracker has root, supervisor, or administrator privileges on the box. In other words, the cracker has total control of the machine and, at any time, could totally down or otherwise destroy the network.
Another issue is familiarity. Most crackers know two or more operating systems intimately from a user standpoint, but generally only one from a cracking standpoint. In other words, these folks tend to specialize. Few crackers are aware of how to crack multiple platforms. For example, perhaps one individual knows VAX/VMS very well but knows little about SunOS. He will therefore target VAX stations and ultimately, perhaps through experience, DEC Alphas.
Universities are major targets in part because they possess extreme computing power. For example, a university would be an excellent place to run an extensive password cracking session. The work can be distributed over several workstations and can thus be accomplished much more quickly than by doing it locally. Another reason universities are major targets is that university boxes usually have several hundred users, even in relatively small network segments. Administration of sites that large is a difficult task. There is a strong chance that a cracked account can get lost in the mix.
Other popular targets are government sites. Here, you see the anarchistic element of the cracker personality emerging: the desire to embarrass government agencies. Such an attack, if successful, can bring a cracker great prestige within the subculture. It does not matter if that cracker is later caught; the point is, he or she cracked a supposedly secure site. This telegraphs the news of the cracker's skill to crackers across the Internet.
Although the legal definition of an attack suggests that it occurs only after the act is completed and the cracker is inside, it is my opinion that the mere undertaking of actions that will result in a network break-in constitutes an attack. The way I see it, you are under attack the moment a cracker begins working on the target machine.
The problem with that position is that sometimes, partly out of sophistication and partly out of opportunity, a cracker will take some time to actually implement an attack. For example, a series of fishing expeditions may occur over a period of weeks. These probes in themselves could not reasonably be called attacks because they do not occur contiguously. If a cracker knows that logs are being run, he may opt for this "slow boat to China" approach. The level of paranoia in system administrators varies; this is not a quality that a cracker can accurately gauge without undertaking some action (perhaps trying a mock attack from a temporary address and waiting for the response, repercussions, or activity from the sysad). However, the majority of system administrators do not fly off the handle at a single instruction from the void unless that instruction is quite obviously an attack.
An example of an obvious attack is when the log reveals the attempt of an old sendmail exploit. This is where the cracker issues two or three command lines on port 25. These commands invariably attempt to trick the server into mailing a copy of the /etc/passwd file back to the cracker. If a system administrator sees this, he will obviously be concerned. However, contrast that with evidence of a showmount query. A system administrator may well know that a showmount query is an ominous indication, but it cannot be indisputably classed as an attempted intrusion. In fact, it is nothing more than evidence of someone contemplating an intrusion, if that.
These techniques of gradually gaining information about a system have their advantages and their pitfalls. For example, the cracker may come from different addresses at different times, quietly knocking on the doors (and checking the windows) of a network. Sparse logging evidence from disparate addresses may not alarm the average system administrator. In contrast, a shotgun approach (heavy scanning) will immediately alert the sysad to a problem. Unless the cracker is reasonably certain that an exploit hole exists on a machine, he will not conduct an all-out scanning attack (at least, not if he is smart).
If you are just getting started in security, the behavior of crackers is an important element of your education; this element should not be neglected. Security technicians usually downplay this, because they maintain a high level of disdain for the cracker. Nonetheless, even though sites employ sophisticated security technology, crackers continue to breach the security of supposedly solid servers.
Most crackers are not geniuses. They often implement techniques that are tried, true, and well known in the security community. Unless the cracker is writing his own tools, he must rely on available, existing tools. Each tool has limitations peculiar to its particular design. Thus, from the victim's point of view, all attacks using such tools will look basically the same. Attacks by crackers using strobe will probably look identical as long as the target machine is, say, a SPARC with SunOS 4.1.3. Knowing those signatures is an important part of your security education. However, the study of behavior goes a bit deeper.
Most crackers learn their technique (at least the basics) from those who came before them. Although there are pioneers in the field (Kevin Mitnik is one), the majority of crackers simply follow in the footsteps of their predecessors. These techniques have been described extensively in online documents authored by crackers, and such documents are available at thousands of locations on the Internet. In them are extremely detailed examples of how to implement a particular class of attack.
The new cracker typically follows these instructions to the letter, often to his detriment because some attack methods are pathetically outdated (solutions have since been devised and the cracker employing them is wasting his own time). If you examine such an attack in your logs, it may look almost identical to sample logs posted by security professionals in various technical presentations designed with the express purpose of illustrating cracking examples.
However, there comes a point within a cracker's experience where he begins to develop specialized methods of implementing attacks. Some of these methods emerge as a result of habit; others emerge because the cracker realizes that a tool can be used for more than its express purpose. These types of attacks, called hybrid attacks, are where one or more techniques are used in concert to produce the ultimate end. (The example given in the preceding paragraphs is where an apparent denial-of-service attack is actually one phase of a spoofing attack.) Incredibly, there may be crackers who still use traditional type-one-command-at-a-time techniques, in which case, you will see all sorts of interesting log messages.
TIP: You can create scripts that will extract such attacks from logs. These scripts are really nothing more than powerful regex searches (Perl is most suitable for this) that scan log files for strings that commonly appear during or after such an attack. These output strings generally differ only slightly from platform to platform. The key is, if you have never seen those strings, generate some. Once you know the construct of the output, you will know what to scan for. Likewise, check out some of the tools I reference later in this chapter. These tools are designed for wholesale scanning of large log files.
In any event, studying the behavior of crackers in actual cracking situations is instructive. There are documents of this sort on the Internet, and you should obtain at least two or three of them. One of the most extraordinary papers of this class was written by Bill Cheswick, then of AT&T Bell Laboratories. Cheswick begins this classic paper as follows:
Cheswick forwarded the password file and allowed the cracker to
enter a protected environment. There, the cracker was observed as he tried
various methods to gain leveraged access and ultimately, to delete all
the files. The attack had an apparent originating point at Stanford University,
but it was later determined that the cracker was operating from the Netherlands.
At the time, such activity was not unlawful in the Netherlands. Therefore,
though the calls were ultimately traced and the cracker's identity known,
he was reportedly untouchable. At any rate, the cracker proceeded to make
a series of clumsy attempts to crack a specific machine. The story that
Cheswick relates from there is truly fascinating. Cheswick and his colleagues
created a special, protected (chroot) environment in which the cracker
was free to crack as he pleased. In this way, the cracker could be observed
closely. The paper contains many logs and is a must read.
Other such reports exist. A particularly scathing one was authored by Tsutomu Shimomura, who had a cracker who closely resembled the Berferd mentioned above. The individual claimed to be from the Mitnik Liberation Front (the name of this so-called organization says it all). In any event, this individual "compromised" a baited machine, similar to the one that Bellovin reportedly constructed. Shimomura's commentary is interlaced between failed attempts by the cracker to accomplish much. There are logs of the sessions. It is an interesting study.
Cross Reference: Find Cheswick's "An Evening With Berferd In Which a Cracker is Lured, Endured and Studied" online at ftp://research.att.com/dist/internet_security/berferd.ps.
NOTE: Tsutomu Shimomura and Weitse Venema were also involved in this case, which spanned a fairly lengthy period of time. Shimomura reportedly assisted in capturing the network traffic, while Venema monitored the cracker (and his associates) in the Netherlands. Also, Cheswick reports that Steve Bellovin constructed a throwaway machine that they intended to use for such cases. They reasoned that such a machine would provide a better environment to observe a cracker at work, because the machine could actually be compromised at a root level (and perhaps even the file system could be destroyed). They would simply locate the machine on a network segment on which a sniffer could also be installed. Thus, if the cracker destroyed the file system of the instant machine, they could still reap the benefit of the logs. This is truly an important paper. It is humorous, entertaining, and enormously instructive.
NOTE: As it happens, Steve Bellovin did provide a dedicated bait machine, which would later become the model for other such machines. In the referenced paper, there is an extensive discussion of how to build a jail like the one the folks at Bell Labs used for the Berferd.
Another engrossing account was authored by Leendert van Dorn, from Vrije University in the Netherlands. It is titled "Computer Break-ins: A Case Study" (January 21, 1993). The paper addresses various types of attacks. These techniques were collected from actual attacks directed against Vrije University. Some of the attacks were quite sophisticated.
Cross Reference: Shimomura's paper is located online at http://www.takedown.com/evidence/anklebiters/mlf/index.html.
Perhaps a better-known paper is "Security Breaches: Five Recent Incidents at Columbia University." Because I analyze that paper elsewhere in this text, I will refrain from doing so again. However, it is an excellent study (some 23 pages in all) that sheds significant light on the behavior of crackers implementing attacks.
Cross Reference: Find van Dorn's account online at http://www.alw.nih.gov/Security/FIRST/papers/general/holland.ps.
Gordon R. Meyer wrote a very interesting paper titled "The Social Organization of the Computer Underground" as his master's thesis at Northern Illinois University. In it, Meyer analyzed the computer underground from a sociological point of view and gathered some enlightening information. The paper, although dated, provides excerpts from radio and television interviews, message logs, journals, and other publications. Although Meyer's paper does not reveal specific methods of operation in the same detail as the papers mentioned earlier, it does describe (with considerable detail and clarity) the social aspects of cracking and crackers.
Cross Reference: "Security Breaches: Five Recent Incidents at Columbia University" can be found online at http://www.alw.nih.gov/Security/FIRST/papers/general/fuat.ps.
Cross Reference: Meyer's paper, written in August, 1989, is located online at http://www.alw.nih.gov/Security/FIRST/papers/general/hacker.txt.
FIGURE 26.1.
The Sams crack level index.
The majority of crackers capitalize on the holes we hear about daily in security newsgroups. If you have frequented these groups (or a security mailing list) you will have read these words a thousand times:
There are some instances in which a denial-of-service attack can be more serious. Certain, obscure configurations of your network could foster more threatening conditions. Christopher Klaus of Internet Security Systems defined several such configurations in a post concerning denial-of-service attacks. In that posting, Klaus wrote:
TIP: If you uncover evidence of a denial-of-service attack, you should look elsewhere on the system for possible intrusions. Flooding and denial-of-service attacks are often precursors (or even integral portions) of a spoofing attack. If you see a comprehensive flooding of a given port on one machine, take note of the port and what it does. Examine what service is bound to it. If that service is an integral part of your internal system--where other machines use it and the communication relies on address authentication--be wary. What looks like a denial-of-service attack could in fact be the beginning of a breach of network security, though generally, denial-of-service attacks that last for long periods of time are just what they appear to be: nuisances.
If the attack is a syn_flood attack, there are some measures you can take to identify the cracking party. Currently, four major syn_flooding utilities are floating around on the Internet. At least two of these tools have a fundamental flaw within them that reveals the identity of the attacker, even if indirectly. These tools have provisions within their code for a series of PING instructions. These PING instructs carry with them the IP address of the machine issuing them. Therefore, if the cracker is using one of these two utilities, he is telegraphing his IP address to you for each PING. Although this will not give you the e-mail address of the party, you can, through methods described earlier in this book, trace it to its ultimate source. (As noted, traceroute will reveal the actual network the cracker is coming from. This is generally the second-to-last entry on the reverse traceroute lookup.) The problem with this, however, is that you must log heavily enough to capture all the traffic between you and the cracking party. To find that IP address, you will have to dig for it. At any rate, you have a 50 percent chance of the cracker using such a flawed utility.
Cross Reference: Klaus's posting can be found online at http://vger.alaska.net/mail/bos/msg00002.html.
Most denial-of-service attacks represent a relatively low-level risk. Even those attacks that can force a reboot (of over-utilization of a processor) are only temporary problems. These types of attacks are vastly different from attacks where someone gains control of your network. The only truly irritating thing about denial-of-service attacks is that in the same way that they are low-level risks, they are also high-level possibilities. A cracker implementing a denial-of-service attack need have only very limited experience and expertise. These attacks are therefore common, though not nearly as common as mail bombings.
NOTE: The remaining two utilities for syn_flooding do not have this PING flaw. The developers of these tools were a bit more sophisticated. They added a provision to randomize the purported IP address. This naturally presents a much more difficult situation to the victim. Even low-level analysis of the received packets is a waste of time. However, to the inexperienced system administrator, this could be a bit confusing. Tricky, right?
As for mail bombings, the perpetrators are usually easily tracked. Furthermore, bozo files (kill files) and exclusionary schemes basically render these attacks utterly harmless (they ultimately bring more sorrow to the perpetrator than anyone). The only real exception to this is where the bombing is so consistent and in such volume that it cripples a mail server.
Other level-one intrusions consist of knuckleheads initiating Telnet sessions to your mail or news server, trying to ascertain shared out directories and whatnot. As long as you have properly secured your network, these activities are harmless. If you haven't properly configured shares, or if you are running the r services (or other things you shouldn't), some of these garden- variety level-one techniques can expand into real trouble.
Local attacks are a bit different. The term local user is, I realize, a relative one. In networks, local user refers to literally anyone currently logged to any machine within the network. Perhaps a better way to define this is to say that a local user is anyone who has a password to a machine within your local network and therefore has a directory on one of your drives (regardless of what purpose that directory serves: a Web site, a local hard disk drive on one of the workstations, and so forth).
NOTE: Microsoft Windows 95 does not have granular access control and therefore, barring installation of some third-party, access-control device, Windows 95 networks are completely insecure. Because of this, level-two attacks are critical and can easily progress to levels three, four, five, and six in seconds. If you run such a network, immediately get an access-control device of some sort. If you do not, anyone (at any time) can delete one or more critical files. Many programs in the Windows 95 environment rely on file dependencies. As long as you run a Windows 95 network connected to the Internet (without access control or closing the holes in Internet Explorer), it is only a question of how long before someone mangles your network. By deleting just a few files on a Windows 95 network, a cracker can incapacitate it permanently. If you have the ability to do so, monitor all traffic to ports 137-139, where the sharing process occurs. Furthermore, I would strictly prohibit users within that network from installing Web or FTP servers. If you are running the Microsoft platform and want to provide servers open to the outside world (an idea that I would furiously argue against), get NT.
The threat from local users correlates directly to what type of network you are maintaining. If you are an ISP, your local users could be anyone; you have probably never met or spoken to 90 percent of your local users. As long as their credit card charges ring true each month, you probably have little contact with these folks even by e-mail (barring the distribution of monthly access or maintenance reports; this interaction doesn't really count as contact, though). There is no reason to assume that these faceless persons are not crackers. Everyone but your immediate staff should be suspect.
An attack initiated by a local user can be either pathetic or extremely sophisticated. Nevertheless, no matter what level of expertise is behind these attacks, will almost invariably originate over Telnet. I have indicated before that if you are an ISP, it is an excellent idea to isolate all shell accounts to a single machine. That is, logins should only be accepted on the one or more machines that you have allocated for shell access. This makes it much easier to manage logs, access controls, loose protocols, and other potential security issues.
These machines should be blocked into their own networked segment. That is, they should be surrounded by either routers or hubs, depending on how your network is configured. The topology should ensure that bizarre forms of hardware address spoofing cannot leak beyond that particular segment. This brings up some issues of trust, a matter I address later in this book.
TIP: In general, you should also segregate any system boxes that are going to house user-created CGI.
There are only two kinds of attack you will encounter. The less serious one is the roving user, a cracker who is new to the subject and therefore looks around for things (oh, they might print the passwd file to SDTOUT, see if they can read any privileged files, and whatnot). Conversely, you may encounter an organized and well-thought-out attack. This is where the attacker already knows your system configuration well. Perhaps he previously assessed it from an account with another provider (if your system gives away information from the outside, this is a definite possibility).
For those using access-control-enabled environments, there are two key issues regarding permissions. Each can affect whether a level-two problem escalates into levels three, four, or five. Those factors are
The second contingency is more common than you think. In fact, it crops up all the time. For example, according to the CERT advisory titled "Vulnerability in IRIX csetup" (issued in January, 1997):
TIP: Many security tools come with tutorials about vulnerabilities. SATAN is a great example. The tutorials included with SATAN are of significant value and can be used to understand many weaknesses within the system, even if you do not run UNIX. For example, suppose you are a journalist and want to gain a better understanding of UNIX security. You don't need UNIX to read the HTML tutorials included with SATAN.
Take a good look at this advisory. Note the date. This is not some ancient advisory from the 1980s. This appeared very recently. These types of problems are not exclusive to any one company. Holes are routinely found in programs on every manner of operating system, as noted in the CERT advisory titled "Vulnerability in Solaris admintool" (August, 1996):
Cross Reference: Find this advisory online at http://www.fokus.gmd.de/vst/Security/cert/0073.html.
It makes no difference what flavor you are running. Bugs are posted for almost all operating systems. Most networked systems see at least one advisory a month of this nature (by this nature, I mean one that can lead to leveraged or even root access). There is no immediate solution to this problem because most of these holes are not apparent at the time the software is shipped. The only solution is that you subscribe to every mailing list germane to bugs, holes, and your system. In this respect, security is a never-ending, learning process.
Cross Reference: Find this advisory online at http://www.fokus.gmd.de/vst/Security/cert/0050.html.
There are some techniques that you can employ to keep up with the times. First, if you subscribe to several mailing lists, you will be hammered with e-mail. Some lists generate as many as 50 messages a day. On UNIX platforms, this is not much of a problem, because you can control how these messages are written to the disk at their time of arrival (by trapping the incoming address and redirecting the mail to a particular directory and so forth). In a Microsoft Windows environment, however, that volume of mail can be overwhelming for someone busy with other tasks. If you are the system administrator of a network running NT, there are several actions you can take. One is to direct different lists to different accounts. This makes management of incoming mail a bit easier (there are also products on the market for this sort of thing). Nonetheless, no matter what platform you use, you should fashion scripts to analyze those mail messages before you read them. I would install Perl (which is also available for NT) and use it to scan the messages for strings that would likely appear in a post relevant to your specific configuration. With a little effort, you can even create a script that rates these hits by priority.
The highest percentage of these holes arise through misconfiguration of your server, bad CGI, and overflow problems.
NOTE: In cases where you cannot cut the user loose entirely (perhaps the user is an employee), you can give warnings and make the user's position contingent on compliance. Carefully document the incident as well, so that if further problems occur, the user has no case for a wrongful termination action if fired.
The standards of evidence in an Internet criminal case are not exactly settled. Certainly, the mere act of someone trying to retrieve your /etc/passwd file by sendmail will not support a criminal case. Nor will evidence of a handful of showmount requests. In short, to build an iron-clad case against an intruder, you must have some tangible evidence that the intruder was within your network or, alternatively, some tangible evidence identifying the intruder as the one who downed your server in a denial-of-service attack. To do this, you must endure the brunt of the attack (although you can institute come safeguards to ensure that this attack does not harm your network).
My advice in such a situation would be to call in not only some law enforcement but also at least one qualified security firm to assist in snagging the offender. The most important features of such an operation are logs and, of course, locating the perpetrator. You can provide the logs on your own. However, as far as tracing the individual, you can only go so far. You might start with a simple traceroute and, before you're finished, you may have implemented a dozen different techniques only to find that the network from which the perpetrator is hailing is either also a victim (that is, the cracker is island hopping), a rogue site, or even worse, located in a country beyond the reach of the U.S. Justice Department. In such cases, little can be done besides shoring up your network and getting on with your business. Taking any other course of action might be very costly and largely a waste of time.
© Copyright, Macmillan Computer Publishing. All rights reserved.